Enhanced self-assembling and self-configuring microservices

ABSTRACT

A method for managing systems with interrelated microservices with self-assembling and self-configuring microservices includes receiving at a first micro service a service request from a client. A determination is the made whether the first micro service is capable of processing the service request. If the first micro service is capable of processing the service requests, then processing the service request; if the first micro service cannot process the service request then routing the service request to a first stem service. The first stem service determines whether there is a second micro service that can process the service request. If the second micro service that can process the service requests exists, then forwarding the service request to the second micro service for processing. If there is no second micro service that can service the service requests then morphing the first stem service into a micro service that can service the service request.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/376,745, entitled ENHANCED SELF-ASSEMBLING AND SELF-CONFIGURINGMICOSERVICES, filed on Jul. 15, 2021, which is a continuation of U.S.patent application Ser. No. 16/709,735, entitled ENHANCEDSELF-ASSEMBLING AND SELF-CONFIGURING MICOSERVICES, filed on Dec. 10,2019 (now U.S. Pat. No. 11,146,658), which is a continuation-in-part ofU.S. patent application Ser. No. 16/526,160, entitled SELF-ASSEMBLINGAND SELF-CONFIGURING MICROSERVICES, filed on Jul. 30, 2019 (now U.S.Pat. No. 11,165,627). All sections of the aforementioned application(s)and/or patent(s) are incorporated herein by reference in their entirety.

TECHNICAL FIELD

The present disclosure relates to the management of systems withinterrelated services. More particularly, the disclosure relates to amethod, system, and computer program for managing systems withinterrelated microservices with self-assembling and self-configuringmicroservices.

BACKGROUND

Replacement of large, multi-feature, operations support systems (OSSsystems) (e.g. Inventory management, fault management, etc.) withsmaller, more focused, systems (microservices) effectively replaces eachlarge OSS with (on average) N microservices. Since the OSS are mostlyinterconnected, the number of interconnections among the microservicesis larger by order of N-squared.

The traditional methods in managing an OSS infrastructure involveplanning the OSS functionality and interconnections (i.e. interfaceagreements), by a central team of architects/engineers. After each OSSmodule is ready, each of its interfaces is “integration tested” withother systems (typically called end-to-end test) and is then put intoproduction.

Communication service providers (CSPs) are transitioning to OSSarchitectures based on microservices. Microservices are an architecturaland organizational approach to software development where software iscomposed of small independent services, deployed in a host (physical orvirtual machine), that communicate over well-defined applicationprogramming interfaces (APIs). These services are owned by small,self-contained teams. Microservices are autonomous. Each componentservice in a microservices architecture can be developed, deployed,operated, and scaled without affecting the functioning of otherservices. Services do not need to share any of their code orimplementation with other services. Any communication between individualcomponents happens via well-defined APIs. Microservices are specialized.Each service is designed for a set of capabilities and focuses onsolving a specific problem. If developers contribute more code to aservice over time and the service becomes complex, it can be broken intosmaller services.

The microservice architecture provides agility. Microservices foster anorganization of small, independent teams that take ownership of theirservices. Teams act within a small and well understood context and areempowered to work more independently and more quickly. This shortensdevelopment cycle times.

Microservices provide flexible scaling. Microservices allow each serviceto be independently scaled to meet demand for the application feature itsupports. This enables teams to right-size infrastructure needs,accurately measure the cost of a feature, and maintain availability if aservice experiences a spike in demand Microservices provide for easydeployment. Microservices enable continuous integration and continuousdelivery, making it easy to try out new ideas and to roll back ifsomething doesn't work. The low cost of failure enables experimentation,makes it easier to update code, and accelerates time-to-market for newfeatures. Microservices architectures do not follow a “one size fitsall” approach. Teams have the freedom to choose the best tool to solvetheir specific problems. As a consequence, teams building microservicescan choose the best tool for each job. Dividing software into compactmodules enables programmers to reuse the code for multiple purposes. Aservice written for a certain function can be used as a template foranother feature. Unlike a monolithic architecture, where the failure ofa single component can cause the whole application to fail,microservices failure result in the degradation of functionality and notthe crash of the application.

In a microservices environment, the “architect” team has to considerN-times more components (evolving on different schedules) and N-Squareda greater number of interfaces which, due to their numbers, can easilyfall out of sync (in terms of compatibility). The end result introducesa number of problems. One problem is that revisions get out of sync (onemicroservice upgrades and breaks other microservices downstream, e.g.its clients). Another problem is that load balancing becomes a majorissue as it is difficult to foresee how microservices put loads on othermicroservices, resulting in slow performance and crashes. Yet anotherproblem occurs when microservices functionality overlaps with othermicroservices or gaps are introduced into the infrastructure which arenot covered by any microservices. With the use of microservicestroubleshooting becomes very difficult since it is not easily understoodwhether the problem is with one microservice, its downstream services,or a design flaw. These issues hinder the migration to microservices,cause the microservices-based OSS infrastructure to not functionproperly, or both, which in either case can result in significantoperations cost along with loss of productivity and savingsopportunities.

SUMMARY

One general aspect includes a method that includes the step of receivingat a first micro service in a plurality of micro-services disposed in asystem, a service request from a client. The method the determineswhether the first micro service is capable of processing the servicerequest; and if the first micro service is capable of processing theservice requests, then processing the service request. If the firstmicro service cannot process the service request then the servicerequest is routed to a first stem service. The first stem servicedetermines whether there is a second micro service that can process theservice request. If the second micro service can process the servicerequests, then forwarding the service request to the second microservice. If there is no second micro service that can service theservice requests then morphing the first stem service into a microservice that can service the service request.

Implementations may include one or more of the following features. Themethod further including establishing a minimum number of stem servicesto be active in the system. The method further including determining anumber of stem services active in the system. The method furtherincluding determining if the number of stem services active in thesystem is less than the minimum number of stem services to be active inthe system. The method further including spinning up a stem service ifthe number of stem services active in the system is less than theminimum number of stem services to be active in the system. The methodwhere the plurality of micro-services in the first stem service eachinclude a client routing component, a micro service directory componentand a process instantiation and control component. The method where thestep of morphing the first stem service into a micro service that canservice the service request includes loading rules stored in the firststem service.

One general aspect includes a system including: a plurality ofmicro-services and stem services stored in the system and a memory forstoring computer instructions. The system further includes a hostcomputer coupled with the memory, where the host computer, responsive toexecuting the computer instructions, performs certain operations. Theoperations include receiving at a first micro service a service requestfrom a client. The operations also include determining whether the firstmicro service is capable of processing the service request. Theoperations also include if the first micro service is capable ofprocessing the service requests, then processing the service request andif the first micro service cannot process the service request thenrouting the service request to a first stem service. The operations alsoinclude determining at the first stem service whether there exists asecond micro service from the plurality of micro-services that canprocess the service request. If there is a second micro service that canprocess the service requests, then forwarding the service request to thesecond micro service. The operations also include if there is no secondmicro service that can service the service requests then morphing thefirst stem service into a micro service that can service the servicerequest.

Implementations may include one or more of the following features. Thesystem where the host computer, responsive to executing the computerinstructions performs operations further including establishing aminimum number of stem services to be active in the system. The systemwhere the host computer, responsive to executing the computerinstructions performs operations further including determining a numberof stem services active in the system. The system where the hostcomputer, responsive to executing the computer instructions performsoperations further including determining if the number of stem servicesactive in the system is less than the minimum number of stem services tobe active in the system. The system where the host computer, responsiveto executing the computer instructions performs operations furtherincluding spinning up a stem service if the number of stem servicesactive in the system is less than the minimum number of stem services tobe active in the system. The system where the plurality ofmicro-services in the first stem service each include a client routingcomponent, a micro service directory component and a processinstantiation and control component. The system where the host computer,responsive to executing the computer instructions performs operationsfurther including morphing the first stem service into a micro servicethat can service the service request by loading rules stored in thefirst stem service.

One general aspect includes a non-transitory, tangible computer-readablemedium having computer-executable instructions stored thereon which,when executed by a computer, cause the computer to perform a methodincluding receiving at a first micro service in disposed in a system, aservice request from a client. Then determining whether the first microservice is capable of processing the service request. If the first microservice is capable of processing the service requests, then processingthe service request. If the first micro service cannot process theservice request then routing the service request to a first stemservice. Determining at the first stem service whether there exists asecond micro service from the plurality of micro-services that canprocess the service request. If the second micro service that canprocess the service requests exists, then forwarding the service requestto the second micro service; and if there is no second micro servicethat can service the service requests then morphing the first stemservice into a micro service that can service the service request.

Implementations may include one or more of the following features. Thenon-transitory, tangible computer-readable medium where thecomputer-executable instructions which, when executed by a computer,cause the computer to perform a method further including establishing aminimum number of stem services to be active in the system. Thenon-transitory, tangible computer-readable medium where thecomputer-executable instructions which, when executed by a computer,cause the computer to perform a method further including determining anumber of stem services active in the system. The non-transitory,tangible computer-readable medium where the computer-executableinstructions which, when executed by a computer, cause the computer toperform a method further including determining if the number of stemservices active in the system is less than the minimum number of stemservices to be active in the system. The non-transitory, tangiblecomputer-readable medium where the computer-executable instructionswhich, when executed by a computer, cause the computer to perform amethod further including spinning up a stem service if the number ofstem services active in the system is less than the minimum number ofstem services to be active in the system. The non-transitory, tangiblecomputer-readable medium where the computer-executable instructionswhich, when executed by a computer, cause the computer to perform amethod where the step of morphing the first stem service into a microservice that can service the service request includes loading rulesstored in the first stem service.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system architecture 100 for self-managedmicroservices.

FIG. 2 is an illustration of the components of a self-managedmicroservice.

FIGS. 3A-3G are block diagrams illustrating the operation ofself-managed microservices and stem services.

FIG. 4 is a flowchart of a method for a method for self-assembling andself-configuring micro services.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS Glossary

Algorithm. a process or set of rules to be followed in calculations orother problem-solving operations,

API. a set of functions and procedures allowing the creation ofapplications that access the features or data of an operating system,application, or other service.

Base code. (e.g., boiler plate code, infrastructure code, etc.)

Colony of Microservices.

Container. A container is a standard unit of software that packages upcode and all its dependencies so the application runs quickly andreliably from one computing environment to another.

Directory Service. Service that tracks location of microservices.

Docker is a platform and tool for building, distributing, and runningDocker containers.

Docker Containers. Docker containers are Containers that run on DockerEngine. Docker containers are standard and portable. They arelightweight because they share the machine's operating system kernel andtherefore do not require an operating system for application. Dockercontainers are also secure.

HAProxies. HAProxies provides high availability load balancer and proxyserver for TCP and HTTP-based applications that spreads requests acrossmultiple servers. It is written in C and has a reputation for being fastand efficient (in terms of processor and memory usage).

Host resource service. Service that starts a new microservice whenneeded.

HTTP 301/302 code. A 301 redirect means that an address has permanentlymoved to a new location. A 302 redirect means that the move is onlytemporary.

Infrastructure Services. Directory service and Host resources services.

“Kubernetes” are container orchestration systems for Docker containersthat are meant to coordinate clusters of nodes at scale in production inan efficient manner.

“Leader election.” Leader election is the process of designating asingle process as the organizer of some task distributed among severalcomputers (nodes). Before the task is begun, all network nodes areeither unaware which node will serve as the “leader” (or coordinator) ofthe task, or unable to communicate with the current coordinator. After aleader election algorithm has been run, however, each node throughoutthe network recognizes a particular, unique node as the task leader.

“Load Balancing.” Load balancing is the process of distributing networktraffic across multiple servers. This ensures no single server bears toomuch demand By spreading the work evenly, load balancing improvesapplication responsiveness. It also increases availability ofapplications and websites for users.

Microservices. A microservice is an architectural design that separatesportions of a (usually monolithic) application into small,self-containing services. The key idea in microservice architecture isto create small (really small) services, develop and deploy themindependently. Each microservice uses its own database and could bewritten in any programming language. In short, the microservicearchitectural style is an approach to developing a single application asa suite of small services, each running in its own process andcommunicating with lightweight mechanisms, often an HTTP resource API.These services are built around business capabilities and independentlydeployable by fully automated deployment machinery. There is a bareminimum of centralized management of these services, which may bewritten in different programming languages and use different datastorage technologies.

Microservices are built around business capabilities, communicatingthrough lightweight interfaces (REST JSON style requests, in generalthere is no need for an Enterprise Service Bus or complex XML SOAPenvelopes), and having a decentralized control of data where eachservice manages its own data.

Morphing. The act of a stem service being expressed as a specificmicroservice. The morphing (or “expression” in biological terms) isaccomplished by the stem-service loading rules of the new microservice(the system is primarily rule-based, so loading new rules change thebehavior of the service).

“Microservice Proxy”. Microservice Proxy is a microservice that know howto load, shutdown, and route to the non-compliant microservice; so, inthe case of a stem-service morphing (expressing) into a non-compliantmicroservice, it will just load the proxy's rules and those rules willinstantiate the non-compliant microservice and route traffic to it.

Network protocols. are sets of established rules that dictate how toformat, transmit and receive data so computer network devices—fromservers and routers to endpoints—can communicate regardless of thedifferences in their underlying infrastructures, designs or standards.

Non-Compliant Services. Services that do not follow the rules of theregular self-assembling/self-configuring microservice.

Proxy. In computer networks, a proxy acts as an intermediary forrequests from clients to servers for resources. An outbound proxyprovides both security isolation and performance optimization fornetwork traffic. Internal clients protected by a firewall do not havedirect access out to the Internet. Instead, clients send all requests toa proxy that does have external access that then makes the requests onbehalf of the original client. The proxy can optionally cache contentlocally optimizing the use of network bandwidth and providing fasterresponses to clients.

Pseudo-random number generator. A pseudorandom number generator (PRNG),also known as a deterministic random bit generator (DRBG), [1] is analgorithm for generating a sequence of numbers whose propertiesapproximate the properties of sequences of random numbers. ThePRNG-generated sequence is not truly random, because it is completelydetermined by an initial value, called the PRNG's seed (which mayinclude truly random values). Although sequences that are closer totruly random can be generated using hardware random number generators,pseudorandom number generators are important in practice for their speedin number generation and their reproducibility.

Pseudo Random Routing. As used herein pseudo-random routing means thatthe incoming gateway tries to route the request properly, but if itdoesn't and routes it to the wrong microservice, the (wrong)microservice will still take the request and route it to its properdestination. In some cases, the gateway might know about somedestinations (based on caching) and will route the requests to themdirectly, but if it doesn't know the destination, then it will pick arandom microservice and will route the request to it and let themicroservice handle it. In the latter case, a pseudo-random numbergenerator is used to identify the target microservice so as to avoidsending all the unknowns to one instance (in this case it will be theport number that is randomly generated, plus potentially an index of ahost in a list of available hosts).

Rule Engine. A rule engine, which is a set of tools that enable businessanalysts and developers to build decision logic based on anorganization's data. The rule engine applies rules and actions asdefined by end users without affecting how the application runs.

“Service.” A service is a self-contained unit of software that performsa specific task.

“Service Protocols.” Service protocols deal with identifying whichservice is needed to display the contents of each packet.

“Spin up.” Spin up means to create an instance (of say a microservice).

“Stem Services.” Stem Services are microservices that can morph into anyother microservice (i.e. behave similar to a stem cell in a biologicalanalogy).

Virtual Directory Services. A virtual entity realized through adistributed protocol to exchange directory services among eachmicroservice (i.e. so each has view of the entire directory).

Illustrated in FIG. 1 is a block diagram of a system architecture 100for self-managed microservices. The system architecture 100 includes aplurality of external applications 101 that access a plurality of HAPproxies/load balancers 103 which in turn access a plurality of servers105 each having a plurality of microservices 107 (each referred to as aμS in the drawings). The plurality of micro services 107 in a server isreferred to as a colony. In one embodiment the microservices 107 mayaccess persistent data stores 109 which may store rules, metadata, andbasic configurations.

Self-managed microservices are provided through a microservice 200,illustrated in FIG. 2 comprising a client routing component 201, amicroservice directory component 203, a process instantiation andcontrol component 205, a load management component 207, a proxycomponent for noncompliant microservices 209 and a business logiccomponent 211. The micro service 200 runs in a docker container.

The client routing component 201 provides requests proxy and clientredirect capabilities to the microservice 200. The client routingcomponent 201 acts as a proxy for the clients in the event that theclient request needs to be redirected to another microservice. Thiscomponent is a part of each compliant microservice 200. If themicroservice receives a request that is not served by that microservice,the request is routed to a stem service. This routing is handled bysending the client an HTTP redirect response (e.g. HTTP 301 or HTTP 302)to the client with the URL of the stem service, or by proxying therequest (e.g. such as in an HTTP proxy), or other mechanism to ensureclient's requests are routed to the stem service.

The microservice directory component 203 provides a directory exchangeprotocol and stores directory information about all microservicesoperating in the servers 105. The directory contains a set of recordseach having a destination microservice's name, destination information(e.g. URL), service type, timestamp, add/delete flag, load indicator anda verified/unverified flag. The add/delete flag is used to know whethera record is added or deleted. The verified/unverified flag determineswhether a microservice has direct knowledge of the destinationmicroservice which means either the destination is the microserviceitself (each microservice has itself in its directory also), or that themicroservice has directly attempted to contact the destinationmicroservice. If a direct contact succeeds, then an “add” record isadded; if a direct contact fails, then a “delete” record is added. (bothare considered “verified”). Once there is any change in records, anotification is sent to all microservices in the directory about thechange (directory update). If a directory update is received bymicroservice A, then the microservice A's directory records are updatedwith the incoming records with the following notes:

-   -   1. If an existing record is “verified” and the corresponding        incoming record is “unverified” the incoming record is ignored.    -   2. If both incoming and existing records are ‘verified,’ then        the one with the most recent timestamp wins.    -   3. If there is only one ‘add’ or ‘delete’ record per destination        microservice; the most recent timestamp wins with the above two        exceptions (i.e. unverified records do not replace verified        records).

Each microservice can receive a directory request an issue in responseto a directory request. The micro services randomly communicate witheach other and microservice with a directory can provide the directory(list of hosts and ports) to other microservices. In an embodiment themicroservice directory component 203 may include a database includingthe addresses of all microservices in the colony. In operation, themicro service directory component 203 in a micro service A may send acommunication to a micro service B. if the micro service A does notreceive a response, it senses that microservice B is dead and updatesthe record in the directory. The updated record is then communicated toall micro services in the colony thus ensuring the reliability of thedirectory among the micro services in the colony.

The process instantiation and control component 205 provides thecapability of stem service and morphing based on therules/meta-data-driven arrangement. This is done by the stem processloading the metadata (e.g. rules and/or configuration information) forthe target process. Since these processes are meta-data driven, once youload the new meta-data (rules and configs) the process will behave likethe target process. Note that you can also load specific code for thetarget microservice and let it attach to (i.e. takeover) the currentURL. This way, the next request will be serviced by the “logic” that isloaded into the microservice (either the metadata or the new code thatis attached to the URL).

The load management component 207 provides load exchange protocols andself-destruct dissemination protocol to enable leader's selectionprocess for controlling the number of stem services active in thesystem. The directory service will include a “load indicators” thatshows a process's performance measure. These are one or more indicatorsshowing the performance of the microservice as compared tospecifications. (e.g. throughput is 50% of specs, etc.).

-   -   1. The load management component 207 ensures that when a        microservice is finding a target (either routing a client        request or itself trying to connect to another service), the        microservice considers the load indicator value and if it        determines that the performance is too low, the microservice        will route the request to a stem service to instantiate a new        destination instance. Note that the stem service is also running        the same component so it will make the same determination and        morph into that target as opposed to routing the request to it.        Also, note that during this transfer, the target's performance        might improve, and if so, the stem service with just route the        request into it as opposed to starting another copy.    -   2. If a microservice finds itself idling (i.e. its load        indicators are too low, showing very low utilization), then it        will enter a leader selection algorithm with all other copies of        itself which are also in low utilization. And once a leader is        selected, the leader will shut itself down allowing the        remaining copies to handle the load. The leader selection        algorithm can be one of many that exist that elects a single        microservice among the set and ensures each microservice agrees        to the single leader.

The proxy component for noncompliant microservices 209 provides proxyrouting and docker/Kubernetes drivers. There are several ways to dothis. In all methods, a “proxy” microservice (A) will have all thestandard components (directory service, load management, etc.) plus theability to start and stop the actual microservice being proxied (B).Also, when A starts B, it must know how to route requests to and from B.Depending on the architecture of B, A can proxy requests to and from B(i.e. client sends to A, A sends to B, B responds to A, and A relays tothe client) or can redirect client requests to B (using, for example,HTTP redirects such as HTTP 301 and HTTP 302. A may also monitor B'slogs and provide performance information (e.g. load indicators), etc.based on this information. Depending on abilities of B, some of thefunctions may be limited (e.g. if B does not report its load numbers,then A cannot report accurate load numbers and the load balancing of Bwill be limited).

The core of a microservice is its business logic that implements thebusiness rules. The business logic component 211 provides implementationof the business objects, rules and policies. For example, a simplemicroservice may receive a request for data, get the data, verify a zipcode and send the response.

The present disclosure introduces several concepts to eliminate twoinfrastructure services that were disclosed in U.S. application Ser. No.16/516,160. The infrastructure services are the directory service, whichwould track location of microservices; and the host resources services,which would start new microservices as they were needed. The presentdisclosure replaces the infrastructure services by introducing a“stem-service” which is essentially the ‘stem cell’ version of amicroservice. This ‘stem-service’ can morph into any microservice andalso has the ability to start other microservices.

In an embodiment the directory service is now a virtual directoryservice. The directory is a virtual entity realized through a pluralityof microservice directory components 203 and a distributed protocol toexchange directory services among each microservice (i.e. so each hasview of the entire directory). This is accomplished by each microservice200 broadcasting any changes it “directly senses” in the collection ofmicroservices (colony) to others. These changes include when amicroservice morphs into another microservice, when one starts up, whenone ceases to function or respond (dies). This is actually sent byanother microservice whose request to the “dead” microservice fails, andhence learns of the “death”). The microservice directory component 203sends only “directly sensed” changes to other microservices to avoidcatastrophic flood of exchanges (relayed back and forth among nodes).The host resources microservice is replaced by two features (specialstem services and the ability of each microservice to spin up a stemservice) along with leveraging the enhanced load balancing and routingfeatures.

Special stem-services, are microservices that can morph (convert) intoany other microservice (i.e. behave similar to a stem cell). Themorphing (or “expression” in biological terms) is accomplished by thestem service loading rules of the new microservice (the system isprimarily rule-based, so loading new rules change the behavior of theservice). For example, stem service A may morph into stem service B asfollows. Initially stem service A is bound to a port (for example, it issitting at a URL http://www.ms.com:8080/svcA

Example 1

-   -   1. stem service A detaches from the port (now 8080 is free on        this host)    -   2. stem service A starts stem service B and gives him port 8080        to use    -   3. stem service B is started and is now listening on        http://www.ms.com:8080/svcB    -   4. stem service A shuts itself down

Example 2

If process A can load new metadata in real-time, it will just dump itsmetadata (rules) and loads the new metadata (rules). Once these newrules/metadata are loaded, it will start responding tohttp://www.ms.com:8080/svcB instead of http://www.ms.com:8080/svcA. Inan embodiment, the rules for all micro services in the colony may bestored in each micro service so that every micro service will have allof the rules for the other micro services. In an alternate embodimenteach micro service may have access to the rules stored in a centraldatabase.

In an embodiment, the system may support services which arenon-compliant (i.e. do not follow the rules of the regularself-assembling/self-configuring microservice) through having anmicroservice be a proxy for these services. The proxy is a micro servicethat is compliant and whose job is to direct request to and fromnoncompliant micro services. The proxies know how to load, shutdown, androute to the non-compliant microservice; so, in the case of astem-service morphing (expressing) into a non-compliant microservice, itwill just load the proxy's rules and those rules will instantiate thenon-compliant microservice and route traffic to it.

Once a stem-service is morphed (expressed into a specific microservice),the newly “born” microservice will advertise itself as usual and thedistributed directory service (i.e. all other microservices) will knowof its creation.

The second feature to replace the host services is ability of allmicroservices to startup a stem-service and then morph/express into theneeded microservice. Starting up just one service type is simple enoughthat it is practical for all microservices to do it (a simple routineavailable in each microservice base code). The trigger to start astem-service is described below.

There is no change to a microservice shutting itself down due toexcessive number. This may be accomplished by leader selection and thenthe leader terminating itself). Leader election coordinate the actionsperformed by a collection of collaborating microservices by electing onemicroservice as the leader that assumes responsibility for managing theothers. This can help to ensure that microservices do not conflict witheach other, cause contention for shared resources, or inadvertentlyinterfere with the work that other microservices are performing. Thestartup process is simplified in that rather than starting up the neededmicroservice, microservices only spin up stem-services regardless ofwhat is needed. Then the stem-service will morph into any neededmicroservice.

This “morphing” on demand is handled according to a set of protocolsspecified below. The morphing on demand process only requires sufficientstem-services to be available so they can morph as needed; therefore,the microservices are configured to require a minimum set ofstem-services available; if this number is below a minimum in thedistributed directory, then a stem-service is spun up. The minimumnumber of stem services are determined by the network operator based onperformance parameters. Multiple microservices will detect this lack ofsufficient stem-services, so the same leader selection process describedabove is used here so only one stem-service is spun up. The same processis repeated until the minimum number is running.

The morphing of a stem-service to a specific microservice is handledthrough a pseudo-random routing ability available in each microservice.This algorithm consists of two parts: a) If an microservice receives arequest that doesn't belong to it, it will re-route the client (e.g.through HTTP 301/302 codes or RESTful routing) to an instance of astem-service; and b) if a stem service receives a request, it will checkthe directory for that microservice, if it finds one, it will route theclient to it; otherwise, it will morph into the microservice that willhandle that request (the stem-services do not natively handle anyrequest, so any request they receive is interpreted as a request thatwas destined to some other microservice).

FIGS. 3A-3 G illustrate the operation of the microservices and the stemservices.

In FIG. 3A, an initial microservice μS1 303 is spun up in server 302.Upon being spun up, μS1 303 determines if there are a minimum number ofstem services. If there are not a minimum number of stem services μS1303 will spin up a stem service (Stem A 305). The microservice willagain determine if there are a minimum number of micro services, and ifnot, it will spin up additional Stem services (Stem Service B 307 andSem service C 309).

FIG. 3 B illustrates a colony of microservices (μS1 303, μS2 311, μS3313, and μS4 315) and stem services (Stem Service A 305, Stem Service B307 and Stem Service C 309). Only four microservices and three stemservices are shown but more are contemplated as part of this disclosure.

FIG. 3 B illustrates what happens when a client 317 submits a servicerequest to the server 301. The service request is routed to a stemservice or a microservice (e.g. μS2 311) using pseudo-random routing.The microservice that receives the request (μS2 311) determines whetherit can process the request. If the microservice (μS2 311) can processthe request it will do so.

If the microservice μS2 311 cannot process the request, it will routethe request to a stem service (e.g. Stem Service C 309 in FIG. 3 D). TheμS2 311 will send a 302 response back to the client 317 and obtain theURL for the stem service. The client then knows where to send therequest because of the 302 response.

Upon receipt of the service request from the client, Stem Service C 309will determine whether there is a micro service available in the colonythat can process the service request. As shown in FIG. 3 E if the StemService C 309 finds a micro service that can process the service request(e.g. μS4 315), it will send a 302 response to the client providing theaddress of the micro service that can process the request. The clientthen sends the request to μS4 315 which will service the request. Theoriginal micro service (μS2 311) is not involved in the lookup andtransfer of the service request, rather that functionality is providedby the stem service.

As shown in FIG. 3 F, if the Stem Service C 309 does not find a microservice that can process the service request, then it will load theappropriate rules and morph into a micro service (μS5 319) with thebusiness logic to process the service request. As soon as that happensthe directory service will be updated. Then μS5 319 will determine thenumber of Stem Services in the colony. If the morphing of Stem service309 results in fewer than the minimum number of stem services then μS5319 will spin up a Stem Service (e.g. Stem Service D 321 in FIG. 3G.).If there are too many stem services in the colony the number will bereduced by a leader selection process so that access stem services aredisabled. The number of Stem Services is self-regulating. The minimumnumber of stem services is a system setting decided by the networkoperator that establishes a minimum and maximum number of stem servicesto operate in the colony.

Illustrated in FIG. 4 is a flow chart of a method for self-assemblingand self-configuring micro services 400.

In one embodiment of the method 400, in step 401 a network operatorstarts the first micro service.

In step 403 the method 400 determines the number of stem services in thecolony. In step 407, the method 400 determines if there is a minimumnumber of stem services available.

In step 409, in the case where only one micro service has beeninitiated, there will not be any stem service available in the firstmicro service will spin up a first stem service. The method 400 willthen repeat step 403 and 407 until it is determined that the minimumnumber of stem services are available.

In step 413 the method 400 a service request from the client is receivedat a micro service. In the case where there is only the first microservice available client request will be received at the first microservice. In the case where there is a plurality of microservicesavailable, client request will be routed to any available micro serviceusing pseudorandom forwarding.

In step 415 the method 400 determines whether the micro service thatreceives the service request can process the service request. If themicro service that received the service request can process the servicerequest then the request is processed in step 417.

If the micro service that received the service request cannot processthe service request then in step 419 the micro service will forward theservice request to a stem service.

In step 421 to stem service that received the service requestsdetermines whether there exists in the colony any micro service that canprocess the request.

If there is a micro service in the colony that can process the requestand in step 423 the request will be sent to the micro service that canprocess the request and will be processed by that micro service in step424.

If there is no micro service in the colony that can process the requestthen in step 425 the stem service will morph into a micro service thatcan process the request and then process the request in step 426.

After the request has been processed the location of the micro serviceis forwarded to the client in step 427.

The method 900 will once again determine whether the minimum number ofstem services exist in the colony and if not will spin up an additionalstem service.

The behavior of the system then, according to these protocols, atstartup is as follows:

-   -   a) “any” microservice (stem or non-stem) is started; this is the        “seed”; as with any biological system, you need one seed/cell to        start a colony.    -   b) the “seed” (as with any microservice) checks for min number        of stem-service, and since there aren't any it will spin up an        (another) stem-service. In a sense it will start multiplying (as        an embryo)    -   c) the process will continue until sufficient stem-services are        running    -   d) At any point during the previous processes, a client request        could hit the system, and will be routed ‘randomly’ to any of        the running microservice (stem or non-stem).    -   e) If the request lands on the wrong microservice (more than        likely), it will be routed to a stem-service and then the        stem-service will either route it to the correct microservice or        will morph into that microservice.

Note that these are 301/302 type client redirects which means the clientwill automatically reroute the request and learn the location of themicroservice for future requests; this way, this ‘rerouting’ onlyhappens one time and thereafter only on changes (note that this is notnecessary for the algorithm to work, but it makes it more efficient).The net result is that the ‘colony’ of μSs will dynamically replicateand around the demand (i.e. incoming requests) and therefore can morequickly shutdown unused services and focus on what is in demand “rightnow.” This behavior also resembles biological systems by ‘shedding’elements that are not in use (e.g. muscles, bone, etc.) and focus theirenergy on parts are in heavy use.

While the processes or methods described herein may, at times, bedescribed in a general context of computer-executable instructions, themethods, procedures, and processes of the present disclosure can also beimplemented in combination with other program modules and/or as acombination of hardware and software. The term application, or variantsthereof, is used expansively herein to include routines, programmodules, programs, components, data structures, algorithms, and thelike. Applications can be implemented on various system configurations,including servers, network systems, single-processor or multiprocessorsystems, minicomputers, mainframe computers, personal computers,hand-held computing devices, mobile devices, microprocessor-basedconsumer electronics, programmable electronics, network elements,gateways, network functions, devices, combinations thereof, and thelike.

The disclosed embodiments are merely examples that may be embodied invarious and alternative forms, and combinations thereof. As used herein,for example, “exemplary,” and similar terms, refer expansively toembodiments that serve as an illustration, specimen, model or pattern.The figures are not necessarily to scale and some features may beexaggerated or minimized, such as to show details of particularcomponents. In some instances, well-known components, systems, materialsor methods have not been described in detail in order to avoid obscuringthe systems, methods, and computer program products of the presentdisclosure. Therefore, specific structural and functional detailsdisclosed herein are not to be interpreted as limiting, but merely as abasis for the claims and as a representative basis for teaching oneskilled in the art.

The above-described embodiments are merely exemplary illustrations ofimplementations set forth for a clear understanding of the principles ofthe disclosure. Variations, modifications, and combinations may be madeto the above-described embodiments without departing from the scope ofthe claims. All such variations, modifications, and combinations areincluded herein by the scope of this disclosure and the followingclaims.

What is claimed:
 1. A method comprising: routing a service request to afirst stem service of a plurality of stem services disposed in a systemwhen a first micro service of a plurality of micro services disposed inthe system cannot process the service request; and if it is determinedthat there is no second micro service of the plurality of micro servicesthat can process the service request, morphing the first stem serviceinto a micro service that can process the service request.
 2. The methodof claim 1, further comprising establishing a minimum number of stemservices to be active in the system.
 3. The method of claim 1, furthercomprising determining a number of stem services active in the system.4. The method of claim 1, further comprising determining if a number ofstem services active in the system is less than a minimum number of stemservices to be active in the system.
 5. The method of claim 1, furthercomprising spinning up a stem service if a number of stem servicesactive in the system is less than a minimum number of stem services tobe active in the system.
 6. The method of claim 1, wherein each of theplurality of micro services comprises a client routing component, amicro service directory component, or a process instantiation andcontrol component.
 7. The method of claim 1, wherein the morphing thefirst stem service into the micro service that can process the servicerequest comprises loading rules stored in the first stem service.
 8. Asystem comprising: one or more processors; and a memory coupled with theone or more processors, the memory storing executable instructions thatwhen executed by the one or more processors cause the one or moreprocessors to effectuate operations, the operations comprising: routinga service request to a first stem service of a plurality of stemservices disposed in the system when a first micro service of aplurality of micro services disposed in the system cannot process theservice request; and when it is determined that there is no second microservice that can process the service request, morphing the first stemservice into a micro service that can process the service request. 9.The system of claim 8, wherein the operations further compriseestablishing a minimum number of stem services to be active in thesystem.
 10. The system of claim 8, wherein the operations furthercomprise determining a number of stem services active in the system. 11.The system of claim 8, wherein the operations further comprisedetermining if a number of stem services active in the system is lessthan a minimum number of stem services to be active in the system. 12.The system of claim 8, wherein the operations further comprise spinningup a stem service if a number of stem services active in the system isless than a minimum number of stem services to be active in the system.13. The system of claim 8, wherein each of the plurality of microservices comprises a client routing component, a micro service directorycomponent, or a process instantiation and control component.
 14. Thesystem of claim 8, wherein the morphing the first stem service into themicro service that can process the service request comprises loadingrules stored in the first stem service.
 15. A non-transitorycomputer-readable medium having computer-executable instructions storedthereon which, when executed by a computer, cause the computer toperform a method comprising: routing a service request to a first stemservice of a plurality of stem services disposed in a system when afirst micro service of a plurality of micro services disposed in thesystem cannot process the service request; and when it is determinedthat there is no second micro service that can process the servicerequest, morphing the first stem service into a micro service that canprocess the service request.
 16. The non-transitory computer-readablemedium of claim 15, wherein the computer-executable instructions, whenexecuted by the computer, cause the computer to establish a minimumnumber of stem services to be active in the system.
 17. Thenon-transitory computer-readable medium of claim 15, wherein thecomputer-executable instructions, when executed by the computer, causethe computer to determine a number of stem services active in thesystem.
 18. The non-transitory computer-readable medium of claim 15,wherein the computer-executable instructions, when executed by thecomputer, cause the computer to determine if a number of stem servicesactive in the system is less than a minimum number of stem services tobe active in the system.
 19. The non-transitory computer-readable mediumof claim 15, wherein the computer-executable instructions, when executedby the computer, cause the computer to spin up a stem service if anumber of stem services active in the system is less than a minimumnumber of stem services to be active in the system.
 20. Thenon-transitory computer-readable medium of claim 15, wherein themorphing the first stem service into the micro service that can processthe service request comprises loading rules stored in the first stemservice.